1. Technical Field
The present invention relates in general to network technology, and in particular, to secure online communication through a widget in a web page.
2. Description of the Related Art
FIG. 1 is a high level block diagram of a prior art network environment 100 in which online financial payments are made. In the depicted example, network environment 100 includes a network 102, which can include one or more wired and/or wireless public and/or private networks, such as corporate intranet(s) and/or public networks such as the Internet. Coupled to network 102 are at least one company server 104 belonging to an organization, such as a for-profit or not-for-profit business or association, and a separate payment server 106. Company server 104 and payment server 106 are accessed on network 102 via different Internet Protocol (IP) service addresses. In various implementations, payment server 106 may belong to the same organization that operates company server 104 or may alternatively belong to an application service provider that provides payment services on behalf of one or more other organizations (e.g., in exchange for a percentage of the payments received).
Network environment 100 further includes a client device 108, such as a personal computer, laptop computer, mobile phone or other computing device. Client device 108 executes a browser 110 through which a user can access various web pages via network 102.
As further illustrated in FIG. 1, company server 104 hosts a web page 120 containing a sub-window 122 through which the user of client device 108 may initiate financial payments utilizing browser 110. The financial payments can be made in exchange for goods or services or can simply be donations. Payment server 106 hosts a secure payment web page 130 through which financial payments initiated in sub-window 122 are completed. The security of payment web page 130, which is provided through the use of a secure communication protocol such as Hypertext Transfer Protocol over Secure Socket Layer (HTTPS), is indicated in FIG. 1 by shading.
In operation, a user at a client device 108 accesses web page 120 on company server 104 utilizing browser 110. In order to make a financial payment, the user first interacts with sub-window 122, for example, by activating a payment control (e.g., a payment button). The user may also optionally enter personal or transaction-related information within sub-window 122 or a different pop-up window invoked by interaction with sub-window 122. When all required personal and/or transaction-related information is entered, the user may provide a further input, such as selection of a “submit” button, to signify readiness to actually complete the financial payment.
In response to receipt of the input signifying user readiness to complete the financial payment, sub-window 122 or a pop-up window spawned by sub-window 122 redirects browser 110 to a secure payment web page 130 hosted on payment service server 106, as indicated by arrow 124. In performing the redirection, sub-window 122 also transmits the user-entered personal or transaction-related information, if any, to secure payment web page 130.
Following the redirection to payment web page 130, the user completes the financial payment by interacting with payment web page 130 on payment service server 106. For example, the user may enter credit card information or bank account and routing information in payment web page 130 in order to complete the financial payment. Payment server 106 typically confirms completion of the financial payment by the user by serving to browser 110 a different confirmation page (not illustrated).
When making an online financial payment such as that described above, users have two primary concerns, namely, security and authenticity. Security is a concern because users do not want their private personal or financial information intercepted and misused. Authenticity is also a concern because users want payments to be received by the intended recipient rather than an unknown third party. The conventional payment infrastructure described above attempts to address these concerns through authentication with a “trusted” third party that is presumed to be viewed as reliable by users. In many cases, the “trusted” third party provides a badge or seal that is embedded in sub-window 122 and/or a window spawned by sub-window 122. Users can allay concerns regarding the authenticity of the party hosting sub-window 122 by clicking on the badge or seal to establish communication with the “trusted” third party over network 102 to enable confirmation of the authenticity of the party.